🤖 Kimi Code Review

Security & Supply Chain Risk

Cargo.lock: Lines modifying mt-field and mt-koala-bear show a downgrade of num-bigint from 0.4.6 to 0.3.3. This is a concerning regression in cryptographic math dependencies. Verify whether leanEthereum/leanVM at rev 5eba3b1 intentionally uses the older version or if the lockfile needs regeneration.

Cargo.toml (crypto): Lines 15-16, 18-19. Changing the git source from leanMultisig to leanVM while keeping the same revision hash (5eba3b1) assumes the repositories are identical at that commit. Confirm that:

1. leanVM is the legitimate rename/successor of leanMultisig (not a fork or malicious substitution)
2. Commit 5eba3b1 exists in leanVM and contains identical code to the original dependency
3. The repository URL change is accompanied by verification of the upstream crate's authenticity

Consensus Critical: XMSS signature verification (crates/common/crypto/src/lib.rs) depends entirely on these external crates. Any supply chain compromise here would directly affect attestation validation and fork choice safety.

Minor

• CLAUDE.md: Line 257. The parenthetical "(previously leanMultisig)" is helpful for documentation continuity.
• lib.rs: Lines 199, 256. Comment updates correctly reflect the new naming.

Recommendation: Before merging, pin to a new verified tag in leanVM rather than carrying over the old revision hash, ensuring the dependency tree (especially the num-bigint version) is intentional and audited.

Automated review by Kimi (Moonshot AI) · kimi-k2.5 · custom prompt

🤖 Claude Code Review

PR Review: chore: rename leanMultisig references to leanVM

Author: Tomás Grüner | Files: 4 | +28 / -26

Overview

Pure maintenance rename — no logic changes. Updates the upstream git URL from leanEthereum/leanMultisig.git to leanEthereum/leanVM.git at the same revision (5eba3b1), and refreshes comments/docs accordingly. The compiled code is byte-for-byte identical since the revision is unchanged.

What's Good

• The approach is correct: keep the Cargo dependency key as lean-multisig and leave all use lean_multisig:: imports untouched, since the upstream Cargo.toml still names the package lean-multisig. Changing the key would break compilation; the PR correctly avoids that trap.
• The new block comment in Cargo.toml explaining the name discrepancy is a good addition — it will prevent future confusion when someone sees a dependency named lean-multisig pointing at a repo called leanVM.
• All 18 lock-file entries are updated consistently.
• The PR description explicitly verifies the redirect and confirms cargo check -p ethlambda-crypto passes.

One Item Worth Discussing

num-bigint version correction in Cargo.lock (lines ~4818, ~4832)

- "num-bigint 0.4.6",
+ "num-bigint 0.3.3",

mt-field and mt-koala-bear had num-bigint 0.4.6 recorded in the old lock file but now resolve to 0.3.3. The PR notes this as "corrected to the true tree." This is a 3.x → 4.x downgrade in a transitive dependency, but since the revision (5eba3b1) is the same, the old lock file entry was simply stale/wrong — the actual upstream code at that commit requires 0.3.3.

This is fine, but if CI wasn't previously doing a full cargo fetch from the leanMultisig URL (e.g. if the old URL was already being redirected silently), it's worth confirming that the 0.3.3 entry actually compiles cleanly end-to-end (cargo test --workspace --release), not just cargo check. cargo check skips some codegen that could expose version-mismatch issues in proc-macro or build.rs dependencies.

Minor Nits

• CLAUDE.md line 257: "Aggregation via leanVM (previously leanMultisig) for efficiency" — the parenthetical is useful now but will become noise once the rename is well-established. Low priority; fine to leave as a transition marker.
• The Cargo.toml comment block says # leanVM (previously leanMultisig) XMSS signature aggregation. The crate package / # is still named lean-multisig upstream, so the dependency key keeps that name. — consider a single-line form to match the project's preference for concise comments, e.g.:
  # leanVM (ex leanMultisig): upstream package is still "lean-multisig", so the key stays.
  Not a blocker.

Verdict

Approve with one suggestion: run cargo test --workspace --release (not just cargo check) before merging to confirm the num-bigint 0.3.3 transitive correction doesn't surface any compilation issue in the full build graph. Everything else is correct and clean.

Automated review by Claude (Anthropic) · sonnet · custom prompt

Greptile Summary

This PR renames upstream git references from leanEthereum/leanMultisig.git to leanEthereum/leanVM.git across Cargo.toml, Cargo.lock, src/lib.rs, and CLAUDE.md, while intentionally keeping the Rust package name (lean-multisig) and import paths (use lean_multisig::) unchanged since the upstream crate itself was not renamed.

• Cargo.toml: Both lean-multisig and leansig_wrapper git URLs updated to leanVM.git at the same rev (5eba3b1); a comment is added explaining why the dependency key retains the old package name.
• Cargo.lock: All 18 affected source URLs updated; mt-field and mt-koala-bear have their num-bigint dependency corrected from 0.4.6 to 0.3.3, which the PR author attributes to a stale resolution in the previous lock file rather than a deliberate version change.
• src/lib.rs / CLAUDE.md: Doc/inline comments updated to say "leanVM" with a "(previously leanMultisig)" note for discoverability.

Confidence Score: 5/5

Safe to merge — this is a mechanical URL rename that keeps the rev pinned and the package name intact.

All changes are URL-only updates in manifests and comments. The upstream rev is unchanged, the Rust package name and all import paths are deliberately preserved, and cargo check is reported clean. The num-bigint version shift in the lock file (0.4.6 → 0.3.3) is a correction of a stale entry rather than an intentional API change, consistent with re-resolving against the canonical URL.

No files require special attention; the Cargo.lock num-bigint correction is worth a glance but aligns with the stated re-resolution rationale.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[ethlambda-crypto crate] -->|depends on| B["lean-multisig\n(package name unchanged)"]
    A -->|depends on| C["leansig_wrapper\n(package name unchanged)"]
    B -->|git source| D["github.com/leanEthereum/leanVM.git\n@ rev 5eba3b1"]
    C -->|git source| D
    D -->|was previously| E["github.com/leanEthereum/leanMultisig.git\n(now redirects to leanVM)"]
    style E fill:#f9f,stroke:#999,stroke-dasharray:5 5
    style D fill:#9f9,stroke:#090

_{Reviews (1): Last reviewed commit: "chore: rename leanMultisig references to..." | Re-trigger Greptile}

🤖 Codex Code Review

1. crates/common/crypto/Cargo.toml and Cargo.lock — this does not look like a pure repo rename. The lockfile shows mt-field and mt-koala-bear now pulling num-bigint 0.3.3 instead of 0.4.6, and both are part of the leanVM dependency subtree. In a consensus-critical XMSS aggregation/verifier path, that is effectively a crypto-backend update, not just a URL move. I would not merge this as a “rename” unless you explicitly audit that upstream tree and add regression coverage proving aggregated proof generation/verification stays byte-for-byte compatible across clients.

I didn’t find a direct Rust logic bug in the touched source files; the code changes in crates/common/crypto/src/lib.rs are comment-only. Residual risk is mainly supply-chain and consensus compatibility from the dependency swap. I couldn’t run a full cargo check here because the sandbox blocks rustup temp-file writes and external fetches, so build/fetch validation is still needed in CI.

Automated review by OpenAI Codex · gpt-5.4 · custom prompt